\ \(em\ This attribute type is defined in the X.400 series of
Recommendations.
.LP
\fINote\ 2\fR
\ \(em\ The postal address will normally contain the postal code.
Requirements may exist to justify the postal code as being a separate attribute type. Specific conditions are applied to a postal address for Physical
Delivery (see Recommendation\ F.401).
.LP
\fINote\ 3\fR
\ \(em\ Depending on the value of the attribute \*QCTN\*U.
.LP
\fINote\ 4\fR
\ \(em\ This attribute type has not yet been defined in
Recommendation\ X.520.
.TS
box center ;
l l.
M Mandatory to \fIreach\fR | an object of this type.
Q {
May be used to reach an object of this type (within a distinguished name
or as a search filter), but may also be part o the directory response.
Additional attribute types may be used for selection criteria within
national implementations.
}
R {
Normally part of the directory response with regard to the request of the
user.
}
\(em {
This attribute type may either be part of a local sub\(hyobject class or
used nationally.
}
.TE
.nr PS 9
.RT
.ad r
\fBTable\ 2/F.500 [T2.500], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.PP
Some terms used in Table\ 2/F.500 are explained in Annex H.
Definitions of other terms can be found in the X.500 series of
Recommendations.
.sp 1P
.LP
5.5
\fINaming of\fR
\fIentries\fR
.sp 9p
.RT
.PP
To reach an entry, a user has to provide some information, a part of which
is essential to the performance of the request (e.g., the provision of
attributes CTN, ORG, CLASS, for an organizational object), as described
in\ \(sc\ 5.2.
.PP
Depending on the knowledge the user has about the naming structure of the
part of the directory information tree (DIT) to which the entry of the
intended object belongs, the request information provided by this user
to reach the intended entry is either the distinguished name of the entry
(in which case the response is unique), or the value of some relevant search
attributes
(already known by the user) arranged in a logical pattern to act as a filter
to reduce as far as possible the number of the directory responses.
.PP
Since distinguished names have to be unambiguous, it is not expected that
they will always be user\(hyfriendly. For instance, a name of a residential
person may include the telephone number and thus be rather difficult to
predict, especially if the telephone number is the information requested
from the directory. It is recognized that the distinguished name (DN) of
an object may not be commonly known, in which case the DN may be acquired
by using a list operation and in some instances a search operation.
.PP
To perform efficiently the search or list operation, it is recommended
that one narrows as far as possible the scope of the search, either by
giving a base object (from which the search starts in the DIT) near enough
to the intended entry (in terms of DIT levels), or by obtaining and using
the
appropriate filtering.
.PP
It should be possible to obtain from the directory which of the
attributes (qualified with \*QQ\*U in Table\ 2/F.500) may be used as part
of the
search filter for a given object class starting from a given base object.
However, it is recognized that the use of this feature across domain boundaries
is subject to national restrictions and bilateral agreements.
.PP
It is expected in most cases that a directory management domain will be
able to provide from previous experience the useful search criteria of
subordinate levels, whether or not they efficiently manage those levels,
without exploring the DIT further for each request. Knowledge of the search
criteria may also be acquired by DUAs from the directory by automatic means,
e.g.,\ by reading the \*Qsearch guide attribute\*U if available.
.PP
It is up to the Directory Management Domain (DMD) managing a given
entry to select from the attribute types specified in \(sc\ 5.4 for use
as search criteria.
.PP
The use of wildcards to replace the value or part of the value of
unknown recommended search criteria should be made possible.
.PP
Phonetic or orthographic extensions, when requested, may be \fIlocally\fR
applied to the provided values for query operations. However, their actual
provision depends on the capabilities of the directory system. The fall\(hyback
mode is phonetic or orthographic extensions not supported.
.RT
.sp 1P
.LP
5.6
\fIQualifications of\fR
\fIattribute types\fR
.sp 9p
.RT
.PP
Some criteria of the selected attribute types require
qualification.
.PP
\*QMandatory\*U in Table 3/F.500 indicates that, if \fIthat\fR attribute
type exists in an entry of the directory, it shall be part of any response
provided, when asked for by the user, and that no combination of access
controls may be kept on attributes which would preclude provision of a
meaningful directory
service, subject to the owner's approval.
.PP
The \*Qrequired length\*U of an attribute type in Table\ 3/F.500 designates
the minimum number of character positions to be made available for the
attribute type to be displayed on the terminal of a user, and can therefore
assist Administrations in defining their attribute values with the assurance
that the attribute value will not be truncated. (The X.500\(hyseries
Recommendations have system qualifications for the maximum length of attribute
types.)
.PP
The system specification does not provide multiple values for country name
and preferred delivery method. All others may be recurring. For example,
an organization may be \*QPadraic Steel\*U and \*QPadraic Steel Company\*U.
Only one value needs to be displayed to the user.
.PP
Table 3/F.500 contains a list of the user\(hyvisible selected attribute
types to be used in the directory service. The figures shown may require
revision in the light of experience.
.bp
.RT
.ce
\fB H.T. [T3.500]\fR
.ce
TABLE\ 3/F.500
.ce
\fBQualifications of attribute types\fR
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(120p) | cw(36p) | cw(36p) .
Attribute type Mandatory Required length
_
.T&
lw(120p) | cw(36p) | cw(36p) .
Business category Yes \ 128 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Common name Yes \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Country name (see Note 1) Yes \ \ 30 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Description Yes 1024 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
{
Destination indicator (public telegram)
} Yes \ \ \ 4 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Facsimile telephone number No \ 150\fR
.T&
lw(120p) | cw(36p) | cw(36p) .
ISDN addresse No \ \ 16 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Knowledge\(hyinformation No \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Locality name Yes \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Member No \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Object class No \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
O/R address MHS (see Note 2) Yes \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Organization name Yes \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Organizational unit name Yes \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Owner No \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Physical delivery office name No \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Post office box No \ \ 40 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Postal address No \ 180 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Postal code (see Note 2) No \ \ 20 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
{
Preferred delivery method (see Note 3)
} Yes \ \ 15\fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Presentation address No \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
{
Registered address (public telegram)
} Yes \ \ 60 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Role occupant No \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Search/Guide Yes \(em\fR
.T&
lw(120p) | cw(36p) | cw(36p) .
See also Yes \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Serial number No \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
State or province Yes \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Street address No \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Supported application context No \(em
.T&
lw(120p) | cw(36p) | cw(36p) .
Surname No \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Telephone number No \ \ 16 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Teletex terminal identifier No \ \ 24 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Telex answerback (see Note 2) No \ \ 21 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Telex number (see Note 3) No \ \ 36\fR
.T&
lw(120p) | cw(36p) | cw(36p) .
Title No \ \ 64 \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
User password No \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
User certificate No \(em \fR
.T&
lw(120p) | cw(36p) | cw(36p) .
{
Videotex user number (see Note 2)
} No \ \ 17
.T&
lw(120p) | cw(36p) | cw(36p) .
X.121 address No \ \ 15 \fR
.TE
.LP
\fINote\ 1\fR
\ \(em\ The system specification provides only a 2\(hycharacter length,
to correspond to the ISO 3166 value.
.LP
\fINote\ 2\fR
\ \(em\ The postal address will normally contain the postal code.
Requirements may exist to justify the postal code as being a separate attribute type. Specific conditions are applied to a postal address for Physical Delivery (see Recommendation\ F.401).
.LP
\fINote\ 3\fR
\ \(em\ The system specification provides a shorter field.
.LP
\fINote\ 4\fR
\ \(em\ For some attribute types, values are stored in encoded/compressed
format and will need to be displayed in a non\(hyencoded format or human readable format.
.LP
\fINote\ 5\fR
\ \(em\ See also Recommendation X.520, Annex C.
.nr PS 9
.RT
.ad r
\fBTable\ 3/F.500 [T3.500], p.\fR
.sp 1P
.RT
.ad b
.RT
.LP
.bp
.sp 2P
.LP
\fB6\fR \fBCharacter repertoire and languages\fR
.sp 1P
.RT
.sp 1P
.LP
6.1
\fICharacter repertoire\fR
.sp 9p
.RT
.PP
Directory information will be entered and stored locally using a
character repertoire suitable to the country where the directory is located.
More than one character repertoire may be needed to cover different languages
or to provide for access from different types of communication terminals.
.PP
However, in order to provide international public service, the
character repertoire to be used internationally should be limited to CCITT
standardized sets, i.e.,\ the IA5 and T.61 character repertoires.
.PP
For the intercommunication between public directory services, the
repertoires may be agreed to bilaterally.
.PP
However, where no such agreement exists, the character repertoire to be
used shall consist only of those characters defined as \*Qprintable string\*U
in Recommendation\ X.208. Furthermore, those Administrations which use
character
reportoires other than this repertoire shall provide suitable conversion
of the information into this character repertoire for directory requests
from
Administrations with which no bilateral agreement has been reached.
.PP
Subscribers have to be instructed on the use of the appropriate
character repertoires.
.RT
.sp 1P
.LP
6.2
\fILanguage of requests\fR \fIto the directory and responses from\fR
\fIthe directory\fR
.sp 9p
.RT
.PP
Subject to the conditions in \(sc 6.1, the results of requests to the directory
should normally be provided in the language or languages of the DMD providing
the information. However, the information is presented to the
requestor is a national matter.
.RT
.sp 2P
.LP
\fB7\fR \fBDisplay of a response\fR
.sp 1P
.RT
.PP
Attribute types and values will be displayed to the user, when
required, by converting the values in accordance with Recommendation\ X.408.
.PP
Though it is logical enough that the right response always be sought, in
some cases where no such answer can be provided, and on explicit request
of the requestor, the directory may also provide phonetic and orthographic
extensions corresponding to the intended object.
.PP
For displaying directory responses, the following order is
recommended:
.RT
.LP
a)
the right answer(s);
.LP
b)
the answer(s) approaching the right answer(s) using
conjunctions, particles, articles, as well as extended or
concatenated abbreviations;
.LP
c)
the phonetic and orthographic extensions (e.g.\ plural
instead of singular denominations). It should be noted that
such responses may be erroneous.
.PP
Partial responses, including referrals, should be displayed to the requestor
and properly identified as such. The cause for partial responses
should also be displayed.
.sp 2P
.LP
\fB8\fR \fBOperational issues\fR
.sp 1P
.RT
.sp 1P
.LP
8.1
\fIManagement\fR
.sp 9p
.RT
.PP
It is the responsibility of the Directory Management Domains
(DMDs) to exercise the management of information within their Domains.
Inter\(hyDomain Management is for further study.
.RT
.sp 1P
.LP
8.2
\fIAuthentication\fR
.sp 9p
.RT
.PP
Authentication in this context means that the identity of the
subscriber or user is established. In some cases, the directory service
has to ensure that directory information is released only to authorized
requestor(s), and in some cases it has to ensure that data is modified
only by an authorized originator (e.g.,\ by employing techniques related
to data origin
authentication).
.bp
.PP
Checking and keeping of credentials, when performed, are at the
discretion of the DMD, taking into account the requirements of privacy
of the owner of the information. The precise reason for credential failure
will be
masked from the user. The user will be advised that denial of the request
was because an inappropriate authentication level was encountered.
.PP
See also Recommendation X.509.
.PP
Further study is required.
.RT
.sp 1P
.LP
8.3
\fIAccess control\fR
.sp 9p
.RT
.PP
Access controls are a national matter. When access control
prohibits the return of the information requested, an appropriate code error
code will be returned.
.PP
\fINote\fR \ \(em\ The international application of access control is for
further study.
.RT
.sp 1P
.LP
8.4
\fIOperational actions\fR
.sp 9p
.RT
.PP
Actions performed within a directory can be categorized
as:
.RT
.LP
1)
primary (subscriber/directory) action \(em always in direct
support of a subscriber;
.LP
2)
secondary action in support of a subscriber request, either
serving the subscriber's DUA or an intermediary DSA.
.PP
These actions are qualitatively different, and differ also in what they
imply concerning the obligations of an ADDMD.
.PP
Examples of such interactions can be found in
Recommendation\ X.518.
.RT
.sp 1P
.LP
8.4.1
\fIPrimary (subscriber/directory) action\fR
.sp 9p
.RT
.PP
The public directory service should provide three user\(hyvisible
activities of support, as follows:
.RT
.LP
a)
\fIRequest formation\fR
.LP
In this activity, the subscriber composes a request to the
directory. The way in which these functions are performed is
a national matter.
.LP
b)
\fIPresentation of results\fR
.LP
In this activity, the directory service presents to the
subscriber the results of a previously entered request. The
format, presentation medium and other aspects of result
presentation are a national matter.
.LP
c)
\fISubscriber assistance\fR
.LP
In this activity, the directory service assists the
subscriber by providing instructions on the use of the
directory. The means through which the subscriber asks for
such instruction, and the manner in which an instruction is
delivered, are a national matter.
.sp 1P
.LP
8.4.2
\fISecondary action for subscriber support\fR
.sp 9p
.RT
.PP
In order to provide the public directory service, DMDs shall
cooperate. Such cooperation includes adherence to defined patterns of
interaction, and also includes provision of requested directory information
to one another, subject only to internationally agreed access controls
(or
bilateral arrangements). This technical cooperation among DMDs implies an
equivalent level of cooperation in service terms, especially with regard to
information sharing, among the DMDs. Examples of such interaction can be
found in Recommendation\ X.518.
.RT
.sp 1P
.LP
8.5
\fIMaintenance of the directory information\fR
.sp 9p
.RT
.PP
The service provider has to ensure integrity of the information
contained in the directory. Shadowing (controlled replication) of information
in other DMDs is \fIpermitted\fR by bilateral agreement. The international
application is for further study.
.PP
Creation and modification of directory information by the subscribers may
be permitted by the DMDs concerned.
.bp
.RT
.sp 1P
.LP
8.6
\fIError handling\fR
.sp 9p
.RT
.PP
Error conditions will be returned as a value of an error code for all standardized
operations. The meaning will be displayed according to
national implementations as service error messages to the user.
.PP
See Annex B/F.500 for guidance.
.RT
.sp 1P
.LP
8.7
\fIOperator assistance\fR
.sp 9p
.RT
.PP
For further study.
.RT
.sp 2P
.LP
\fB9\fR \fBQuality of service\fR \fBaspects\fR
.sp 1P
.RT
.sp 1P
.LP
9.1
\fIAvailability\fR
.sp 9p
.RT
.PP
In principle, a public directory service should be available to
subscribers 24 hours a day, seven days a week.
.RT
.sp 1P
.LP
9.2
\fISecurity of directory information\fR
.sp 9p
.RT
.PP
Information in public directories should be given the broadest
dissemination. However, subscribers or users about whom information is
available in a directory should be able to require the entity charged with
the management of the directory to limit access to such information to
ensure their own privacy.
.RT
.sp 1P
.LP
9.3
\fISuccessful directory requests\fR
.sp 9p
.RT
.PP
Normally, a successful directory request will result in a report of all
the requested information, unless it is denied because of authorization
restrictions.
.PP
Requests to the directory which do not provide sufficient information to
execute a reasonable search will normally not lead to a successful
result.
.RT
.sp 1P
.LP
9.4
\fIAccess\fR
.sp 9p
.RT
.PP
Providers of a public directory service should ensure that an
adequate number of access ports are available to accommodate subscribers'
requests for information. In principle, this means that a requestor will
receive a prompt within 15\ seconds as a goal.
.RT
.sp 1P
.LP
9.5
\fIResponse time\fR
.sp 9p
.RT
.PP
Recognizing that responses to requests will be controlled in part by the
level of ambiguity tolerated in requests and the number of DMDs which
shall be traversed to retrieve the information requested, a subscriber
normally should expect an initial acknowledgement regarding his request
within
5\ seconds. The scope and priority of the request may have an impact on the
response time. The requestor may terminate his request at any time.
.PP
A final response (successful or unsuccessful) will depend on the
capabilities of the directories consulted. A response indicating that no
information or incomplete information is available (possibly with hints for
further searches) should be given within one minute.
.PP
\fINote\fR \ \(em\ The figures for quality of service are provisional and
may be revised in the future.
.RT
.sp 2P
.LP
\fB10\fR \fBReferences\fR
.sp 1P
.RT
.sp 1P
.LP
10.1
\fIRecommendations of the X.500 series\fR \ \(em\ Data communication
networks: directory
.sp 9p
.RT
.PP
X.500 The directory \(em Overview of concepts, models and services
.PP
X.501 The directory \(em Models
.PP
X.509 The directory \(em Authentication framework
.PP
X.511 The directory \(em Abstract service definition
.PP
X.518 The directory \(em Procedures for distributed operation
.PP
X.519 The directory \(em Protocol specification
.PP
X.520 The directory \(em Selected attribute types
.PP
X.521 The directory \(em Selected object classes
.bp
.RT
.sp 1P
.LP
10.2
\fIRecommendations of the X.200 series\fR \ \(em\ Data communication
networks: open systems inter
connection\ (OSI)
.sp 9p
.RT
.sp 1P
.LP
10.3
\fIRecommendations of the F.400 series\fR \ \(em\ Message handling and
directory services operations and definition of service
.sp 9p
.RT
.sp 1P
.LP
10.4
\fIRecommendations of the X.400 series\fR \ \(em\ Data communication
networks: message handling systems
\v'1P'
.sp 9p
.RT
.ce 1000
ANNEX\ A
.ce 0
.ce 1000
(to Recommendation F.500)
.sp 9p
.RT
.ce 0
.ce 1000
\fBAbbreviations\fR
.sp 1P
.RT
.ce 0
.ce
\fBH.T. [T4.500]\fR
.ce
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
lw(30p) | lw(150p) .
A {
Additional Optional User Facility
}
.T&
lw(30p) | lw(150p) .
ADDMD {
Administration Directory Management Domain\fR
}
.T&
lw(30p) | lw(150p) .
AVA Attribute Value Assertion
.T&
lw(30p) | lw(150p) .
DIB {
Directory Information Base \fR
}
.T&
lw(30p) | lw(150p) .
DIT {
Directory Information Tree \fR
}
.T&
lw(30p) | lw(150p) .
DMD {
Directory Management Domain \fR
}
.T&
lw(30p) | lw(150p) .
DN Distinguished Name \fR
.T&
lw(30p) | lw(150p) .
DSA Directory Systems Agent\fR
.T&
lw(30p) | lw(150p) .
DUA Directory User Agent \fR
.T&
lw(30p) | lw(150p) .
E {
Essential Optional User Facility
}
.T&
lw(30p) | lw(150p) .
ITU {
International Telecommunication Union \fR
}
.T&
lw(30p) | lw(150p) .
PRDMD {
Private Directory Management Domain \fR
}
.T&
lw(30p) | lw(150p) .
RDN {
Relative Distinguished Name \fR
}
.T&
lw(30p) | lw(150p) .
RPOA {
Recognized Private Operating Agency \fR
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTableau [T4.500], p.5\fR \v'1P'
.sp 1P
.RT
.ad b
.RT
.ce 1000
ANNEX\ B
.ce 0
.ce 1000
(to Recommendation F.500)
.sp 9p
.RT
.ce 0
.ce 1000
\fBService error messages\fR
.sp 1P
.RT
.ce 0
.PP
Error codes produced while performing operations in directory systems are
transformed by the local DUA into service error messages. The
values of the error codes and the meaning are summarized in this Annex.
Standardized service error messages are for further study. The presentation
to the user is a local manner.
.sp 1P
.RT
.PP
See also Recommendation X.511.
.bp
.sp 1P
.LP
B.1
\fIAttribute error\fR
.sp 9p
.RT
.PP
This error is displayed on a per\(hyselection criteria basis
(attribute type) and includes the attribute type, attribute value and problem
reason value. The problem reason values are as follows (see
Table\ B.1/F.500).
.RT
.ce
\fBH.T. [T5.500]\fR
.ce
TABLE\ B\(hy1/F.500
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(42p) | cw(150p) .
Reason value Meaning
_
.T&
cw(42p) | lw(150p) .
1 {
The requested information does not exist for the named entry.\fR
}
.T&
cw(42p) | lw(150p) .
2 {
The syntax of the value used for the distinguished name or the
selection criteria <attribute> is inappropriate. Contact support
staff for assistance.
}
.T&
cw(42p) | lw(150p) .
3 {
Attribute Type <attribute> is not defined for this
<object>. \fR
}
.T&
cw(42p) | lw(150p) .
4 {
Inappropriate matching for the information type
<attribute type>. \fR
}
.T&
cw(42p) | lw(150p) .
5 {
Attribute Type <attribute> or Attribute Value <value> is
not within its constraints.
}
.T&
cw(42p) | lw(150p) .
6 {
<attribute type> or <attribute value> already exists.
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable B.1/F.500 [T5.500], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
B.2
\fIName error\fR
.sp 9p
.RT
.PP
This will be displayed with one of the following reason values
whenever a name provided by the user is detected to have a problem (see
Table\ B.2/F.500).
.RT
.ce
\fBH.T. [T6.500]\fR
.ce
TABLE\ B\(hy2/F.500
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(42p) | cw(150p) .
Reason value Meaning
_
.T&
cw(42p) | lw(150p) .
1 {
The name supplied, <name>, cannot be found.
(\fINote\fR
\ \(em\ ALIAS names are resolved to the actual named entry.)
}
.T&
cw(42p) | lw(150p) .
2 {
<name> is an Alias that can not be properly resolved.
}
.T&
cw(42p) | lw(150p) .
3 {
Part, <attribute type>, of the name used is underfined.
}
.T&
cw(42p) | lw(150p) .
4 {
The syntax of the value used, <attribute value>, is inappropriate.
}
.T&
cw(42p) | lw(150p) .
5 {
List operation is improperly specified.
}
.T&
cw(42p) | lw(150p) .
6 {
An Alias was encountered in an operation where it is not allowed.
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable B.2/F.500 [T6.500], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
B.3
\fIInterconnect error\fR
.sp 9p
.RT
.PP
This error will be displayed whenever the operation cannot be
carried further at this time. The possible access points for continuing the
request are provided in the form: \*QName and Access Point\*U.
.RT
.sp 1P
.LP
B.4
\fIService error\fR
.sp 9p
.RT
.PP
This will be displayed with one of the following reason values
whenever the operation requested has detected a problem that affects the
user service (see Table\ B.3/F.500).
.bp
.RT
.ce
\fBH.T. [T7.500]\fR
.ce
TABLE\ B\(hy3/F.500
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(42p) | cw(150p) .
Reason value Meaning
_
.T&
cw(42p) | lw(150p) .
1 {
The directory system is busy.
}
.T&
cw(42p) | lw(150p) .
2 {
The directory system is presently unavailable.
}
.T&
cw(42p) | lw(150p) .
3 {
System is unable to proceed with the request. Contact
support staff for assistance.
}
.T&
cw(42p) | lw(150p) .
4 {
Information not found in the local system.
[Optionally, the directory service provider may advise the
user that the restriction to use local service information
only should be removed and the request may be re\(hysubmitted
to allow remote directory services to be utlized.]
}
.T&
cw(42p) | lw(150p) .
5 {
Administrative limit exceeded. Contact support staff for assistance.
}
.T&
cw(42p) | lw(150p) .
6 {
Unavailable critical extension.
}
_
.TE
.nr PS 9
.RT
.ad r
\fBTable B.3/F.500 [T7.500], p.\fR
.sp 1P
.RT
.ad b
.RT
.sp 1P
.LP
B.5
\fIUpdate error\fR
.sp 9p
.RT
.PP
This will be displayed with one of the following reason values
whenever the the modify (Add, Change, or Delete) operation(s) requested has
detected a problem (see Table\ B.4/F.500).
.RT
.ce
\fBH.T. [T8.500]\fR
.ce
TABLE\ B\(hy4/F.500
.ps 9
.vs 11
.nr VS 11
.nr PS 9
.TS
center box;
cw(42p) | cw(150p) .
Reason value Meaning
_
.T&
cw(42p) | lw(150p) .
1 {
The update violates directory naming rules.
}
.T&
cw(42p) | lw(150p) .
2 {
The update violates the directory rules for that class of objects.
}
.T&
cw(42p) | lw(150p) .
3 {
Update not allowed because of the object's position in the
directory.
}
.T&
cw(42p) | lw(150p) .
4 {
Update not allowed on an RDN when modifying an entry.
}
.T&
cw(42p) | lw(150p) .
5 {
Entry already exists (relevant for add operation only).